Products such as televisions, mobile phones, DVD players, computers, laptops and other electronics, but also computer programs for such products, implement a large variety of features or functions. These functions are usually called intellectual property (IP) blocks and are provided by IP providers, one or more different companies or other entities. The IP blocks can be provided e.g. as part of chip designs, bitstreams for field programmable gate arrays (FPGAs) or software components.
Because those IP blocks are often made available on a per-product royalty basis, it is desirable to control activation of these IP blocks. That is, an IP block should not be in operation in a product unless this fact has been reported to—and optionally authorized by—the IP provider.
Known solutions in this field include the reporting of a unique identifier associated with the product or IP block to a remote server, whereupon the server returns an authorization code associated with the unique identifier.
Preferably the authorization code is designed in such a way that only with a correct authorization code, the IP block's functionality can be activated. Activation in this context is often implemented by comparing the authorization code with a predefined code available to the IP block. If the codes do not match, the function is not enabled. The authorization code can also be used as a key to unlock or decrypt all or part of the IP block, for example as a decryption key to decrypt a bitstream to be loaded onto an FPGA to cause the FPGA to provide the function in question.
For example each Xilinx Spartan™-3A platform is provided with a unique serial number, referred to as “Device DNA”. The configuration data comprises an authentication value that corresponds to the Device DNA of one particular specimen. Each specimen is provided with a module that verifies whether the Device DNA of the platform matches the authentication value, and enables all or part of the module's functionality only if there is such a match, i.e. if the right configuration data is present.
The authorization code can also be used as a key necessary to process input provided to the IP block, for example as a decryption key for audiovisual content to be decrypted by the IP block or to authenticate the product at a remote server with which data is to be exchanged.
WO 2006/053304, hereby incorporated by reference, discloses a method of determining a key from a physically unclonable function (PUF) provided on such a device. This involves applying error control data to the response from the PUF. The key can then be used e.g. to enable the device to decrypt data such as encrypted audiovisual content, or to authenticate itself to other parties.
Another approach to obtain a key from a PUF is disclosed in B. Skoric, P. Tuyls and W. Ophey, “Robust key extraction from Physical Unclonable Functions”, Applied Cryptography and Network Security ACNS 2005, LNCS 3531, pp. 407-422 (2005). A key is derived from a PUF response by applying certain helper data to the raw response.
A problem in this field is that of cloning. An IP block or even an entire device can be copied in its entirety, i.e. including the unique associated identifier. The IP block in the clone now can be activated using the same authorization code as the IP block in the original. The clone thus does not need to be reported to the remote server, causing under-reporting of activated IP blocks and associated loss of royalties.
To protect against cloning, various solutions are available that provide supposedly unclonable identifiers. For example WO 2006/071380, hereby incorporated by reference, discloses a field configurable device, such as an FPGA, which supports secure field configuration without using a volatile or non-volatile storage for cryptographic keys on the device. This device is provided with a physically unclonable function or PUF that, given a challenge, provides an output which is unique to each particular specimen of the device. However a particular PUF cannot be cloned or reproduced on another device. To ensure that the same output is produced, certain error correcting data needs to be applied to a certain response. This makes it possible to derive the configuration data from the output of a PUF. Only one particular specimen can then successfully reconstruct the configuration data.
Generally speaking these approaches provide protection against unauthorized copying by tying the IP block to a particular specimen of a product by means of a PUF-derived unique item. A copy of the IP block will not operate on a different specimen because the PUF on that specimen will differ from the PUF on the original specimen, which will cause the reconstruction of the configuration data to fail. This may lead to a wrong authentication value or key.
These solutions have in common that, at some point, the identifier needs to be read out and supplied to the remote server to receive the corresponding authorization code. During that process, both the identifier and the authorization code can be observed and recorded. A clone can then still be produced, for example by providing the clone with a simple chip that reproduces the observed identifier. This chip then replaces the memory or other item that originally provides the identifier.
Measures can be taken to hinder the eavesdropping on the activation process, but those are complex and may be beyond the capabilities of many devices. The abovementioned WO 2006/071380 uses public-key encryption to securely transfer the identifier, or recommends the use of a separate enrolment procedure in a trusted environment.
Further, the inventors have realized that the above implicitly assumes a complete trust in the entity that programs or loads this helper data into the component or product in question. In many cases this entity will be a third-party manufacturer that produces the products or intermediary components. This entity should report to the IP provider(s) which and how many products or components he has manufactured, so that the right royalty for the IP blocks he has used can be charged.
However a manufacturer can simply manufacture more using the very same facilities as used for the ‘official’ products. These extra products of course have their own unique PUF, but the manufacturer is able to provide them with the right helper data, which will cause the IP blocks that rely on the PUF to function as if they were installed on the originals. The manufacturer has to know how to provide helper data otherwise he cannot produce the official products. This makes it possible for a manufacturer to pass off these extra, unauthorized products as originals. It is now also possible to under-report the number of products manufactured, which means the IP provider receives lower royalties than to which he is entitled.
Thus there is a need for a method of controlled activation of a function that prevents the activation of cloned devices.